{/* banner prompt: A minimal Scandinavian-style office scene with soft, natural light from a window; on a clean light oak desk, an elegant metal padlock and a small white block with a Google Cloud logo are physically separated by a translucent orange glass cube, creating a sense of a clear, frustrating obstacle.

Additional instructions: an unitree style robot as a runner */}

# From App Engine to Cloud Run: A New Chapter

For a long time, Google App Engine (GAE) has been my go-to for hosting web applications. It’s reliable and handles the heavy lifting of infrastructure. However, Google’s **Cloud Run** has emerged as a compelling successor that promises even better cost efficiency and flexibility.

## What is Cloud Run?

Cloud Run is a fully managed compute platform that automatically scales your stateless containers. Unlike App Engine, which has specific language runtimes, Cloud Run allows you to run **any** language, library, or binary because it is built on the **Knative** (Kubernetes-based) standard.

### Benefits vs. App Engine

1.  **Scale to Zero:** Cloud Run is truly "pay-as-you-go." If no one is using your app, it scales to zero instances, and you pay $0. App Engine's standard environment does this too, but Cloud Run's pricing model is often more granular and cheaper for low-to-medium traffic.
2.  **Containerization:** Since it uses Docker containers, the "it works on my machine" guarantee is much stronger. No more worrying about App Engine-specific constraints or proprietary APIs.
3.  **Concurrency:** A single Cloud Run instance can handle up to 250 requests simultaneously, whereas App Engine instances are often more restricted in how they handle concurrent loads.

## Why the "Trading Journal" Project?

For a project like a **Trading Journal**, Cloud Run is a perfect fit:
*   **Cost Efficiency:** This trading tool is built for a small audience and may get very few visitors, if any. Cloud Run is a good fit because it can scale to zero when nobody is using it, keeping the monthly cost minimal.
*   **Fast Iteration:** If this tool ever evolves, the container-based workflow will make it easier to roll out new calculation logic or UI improvements.
*   **Portability:** If we ever need to move to a full Kubernetes cluster or another cloud provider, the Docker image is already built and ready.

---

# The "Gotcha": Domain Mapping & The 24-Hour Wait

After successfully deploying the Trading Journal to Cloud Run, I hit a major roadblock: **Domain Mapping.** 

I mapped [`sprolo.tyosis.com`](sprolo.tyosis.com) to the service, and then... nothing. I waited 24 hours, and the status remained stuck on **"Waiting for certificate provisioning."**

### How it works under the hood
Cloud Run uses a Kubernetes-based technology stack. The domain mapping service behaves similarly to a **Certbot** container. To provide you with a managed SSL certificate, Google must prove to the Certificate Authority (CA) that it controls your domain. It does this via an ACME challenge: the CA looks for a specific token at your domain's IP address.

### Why the mapping failed
The issue was **Cloudflare**. My domain was using Cloudflare's "Proxy" mode (the Orange Cloud). 

When Google's verification bot tried to check the domain, it didn't see the Google servers; it saw **Cloudflare's edge nodes**. Because Cloudflare was hiding the actual IP from the internet, the authentication and validation process could never finish. Google was effectively shouting into a void, waiting for a challenge response that Cloudflare was intercepting.

### The Fix: The "Grey Cloud" Strategy

To solve this, you have to temporarily "step out of the way" of the SSL handshake:

1.  **Grey Cloud the Record:** In Cloudflare DNS, change the `sprolo` CNAME record from "Proxied" to **"DNS Only"** (Grey Cloud). This exposes the `ghs.googlehosted.com` target directly to the public internet.
2.  **Wait for Google:** Once the proxy is off, Google's verification bot can see the challenge data. In my case, the "Ready" status appeared within about 20 minutes after being stuck for a day.
3.  **Re-enable Proxy:** After the Cloud Run domain status shows a green checkmark and "Ready," you can flip the Orange Cloud back on in Cloudflare to regain your CDN and security benefits.

### Summary
If you are moving to Cloud Run and use Cloudflare, don't wait 24 hours like I did. **Turn off the proxy until the certificate is issued.** Once Google has that initial validation, the routing works perfectly even when you turn the proxy back on.


ecfeee512d771830333c602faaecf4077cedfcb0c744b3d89aca01031ae9a0c1

A practical note on fixing a Cloud Run custom domain that stays stuck on 'Waiting for certificate provisioning' behind Cloudflare. Explains why orange-cloud proxying breaks validation and how switching the record to DNS-only lets the SSL certificate complete.

Cloud Run domain mapping can stay stuck on certificate provisioning when Cloudflare proxying blocks Google's SSL validation.

Cloud Run Domain Mappings with Cloudflare: Why Your SSL is Stuck


## The short version

To connect an office behind a Cisco Meraki MX to a Google Cloud VPC without BGP:

1. **Google Cloud:** create a **Classic VPN** gateway in the same region and VPC as your VMs, reserve a static IP for it, and add a tunnel with **IKEv2**, a pre-shared key, **Route-based** routing, and your office subnet(s) as the remote network ranges.
2. **Meraki:** under **Security & SD-WAN > Site-to-site VPN**, set the MX to Hub (or Spoke), turn on VPN mode for the local subnets, and add a **Non-Meraki VPN peer** with the Google gateway IP, IKEv2, the same pre-shared key, **Static** routing, and the VPC subnet(s) as private subnets.
3. **Allow the traffic:** add a Google Cloud firewall rule that lets the office subnet in. Without it the tunnel shows green and nothing answers.

Three pieces of information have to match on both sides: the two public IPs, the pre-shared key, and the subnets on each end. Most failures are one of those, the IPsec policy, or the missing firewall rule.

The rest of this post is the setup I did for an office network in January 2025, with the screenshots, plus a stronger IPsec policy than the Meraki default and a troubleshooting table.

## The setup and why Classic VPN

The office is the same client site as in my [VoIP crackling post](/blog/2024-11-28-fixing-voip-poor-sound-quality-and-calls-are-cracking/): a **Meraki MX64W** is the gateway, the NBN modem is in bridge mode, and the line is 50 Mbps down and 30 Mbps up.

![Office network: the modem in bridge mode feeds the Meraki MX64W, which serves the computers and a PoE switch for the phones](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/client-network/trak-network-post.svg)

The goal was to let machines in the office reach VMs in Google Cloud (Sydney region, `default` VPC) on their private IPs, and the other way round, without punching port forwards and IP allow-lists through both firewalls.

Google offers two kinds of Cloud VPN:

![Google Cloud Create a VPN page: HA VPN supports dynamic routing (BGP) only and 99.99% SLA; Classic VPN supports static routing, no high availability, IPv4 only](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/site-to-site-vpn-connection/2025-01-15-15-11-31.png)

- **HA VPN** needs BGP. It has two interfaces and a 99.99% SLA, and it's what Google recommends for new setups.
- **Classic VPN** works with static routing, has a single tunnel, and no high availability.

The MX64W rules out BGP. It's an older model whose firmware tops out at the MX 18.1xx train, and the dashboard says so when you look at BGP:

![Meraki warning: BGP is only supported in routed mode in version MX 18.207 or higher](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/site-to-site-vpn-connection/2025-01-15-15-04-44.png)

So Classic VPN with static routes was the option. If your MX runs MX 18.207 or later in routed mode (MX67/68, MX75, MX85 and up), you can use BGP and should look at HA VPN instead. Note that Google has deprecated BGP on Classic VPN, which is why the Classic VPN tunnel form says you can't use dynamic routing (BGP) for connections outside Google Cloud. Classic VPN with static routing is still supported.

On throughput: for a 50/30 Mbps line, the MX64W's VPN capacity isn't the bottleneck. Cisco's datasheet rates the MX64 at 250 Mbps stateful firewall and 100 Mbps VPN throughput. (An earlier version of this post said 50 Mbps VPN; the datasheet figure is 100.) The MX64 range is past end of sale, so if you're buying hardware for this, get a current model.

## What you need before you start

<Table data={{
  "headers": ["Item", "Where to find it", "In my setup"],
  "rows": [
    ["Office public IP (static)", "Meraki: Security & SD-WAN > Appliance status", "The MX's WAN IP (modem bridged, so the MX holds it)"],
    ["Office subnet(s)", "Meraki: Security & SD-WAN > Addressing & VLANs", "192.168.0.0/24 (plus 192.168.0.1 as the MX)"],
    ["Google VPC and region", "Google Cloud: VPC networks", "default, australia-southeast1 (Sydney)"],
    ["Google subnet(s) to reach", "Google Cloud: VPC networks > Subnets", "10.152.0.0/20 (default subnet for Sydney)"],
    ["Pre-shared key", "Generate in the Google tunnel form", "Generated by Google in the tunnel form"]
  ]
}} />

The office needs a **static** public IP on the MX itself. If the MX sits behind another router doing NAT, the tunnel can still work with NAT traversal, but it's simpler and more reliable with the modem in bridge mode, as here.

Also check the subnets don't overlap. If the office used 10.152.0.0/20 too, routing can't work and one side has to be renumbered.

![Meraki LAN config: Single LAN, VLAN interface IP 192.168.0.1/24](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/site-to-site-vpn-connection/2025-01-15-15-28-04.png)

## Step 1: Create the Classic VPN on Google Cloud

Go to **Network Connectivity > VPN** ([console link](https://console.cloud.google.com/hybrid/vpn/list)) and click **Create VPN connection**, then choose **Classic VPN** and **Continue**.

![Google Cloud Network Connectivity VPN page with Create VPN connection](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/site-to-site-vpn-connection/2025-01-15-15-01-39.png)

### The gateway

![Classic VPN gateway form: name classic-vpn, network default, region australia-southeast1 (Sydney), IP address classic-vpn-gateway-ip-address](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/site-to-site-vpn-connection/2025-01-15-15-16-05.png)

- **Network:** the VPC your VMs are in (`default` here).
- **Region:** the region of the VMs you want to reach (`australia-southeast1`). The region can't be changed later.
- **IP address:** pick **Reserve a static IP address** from the dropdown. This is the address the Meraki will connect to, so it must not change.

![Reserve a new static IP address dialog](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/site-to-site-vpn-connection/2025-01-15-15-15-46.png)

### The tunnel

Fill in the tunnel section. These are the values I used:

<Table data={{
  "headers": ["Field", "Value", "Notes"],
  "rows": [
    ["Name", "classic-vpn-tunnel-1", "Anything descriptive"],
    ["Remote peer IP address", "The office's public static IP", "From the Meraki Appliance status page"],
    ["IKE version", "IKEv2", "Must match the Meraki peer"],
    ["IKE pre-shared key", "Click Generate and copy", "You can't view it again after the form closes"],
    ["Routing options", "Route-based", "Dynamic (BGP) is greyed out for Classic VPN"],
    ["Remote network IP ranges", "192.168.0.0/24", "Every office subnet that should reach Google Cloud"]
  ]
}} />

Copy the pre-shared key straight into a password manager. Don't retype it into the Meraki form by hand: one wrong character and the tunnel fails Phase 1 with nothing more helpful than a negotiation error.

**Route-based** creates a static route in the VPC sending the remote ranges into the tunnel. If you have more than one office subnet with VPN mode enabled on the Meraki (my MX also had a Client VPN subnet, 192.168.1.0/24), add each one here that needs to reach Google Cloud. A subnet that isn't listed can send packets to Google, but the replies have no route back.

Click **Create**. It takes a few minutes. When it's done, the gateway shows its public IP, which you need for the Meraki side.

![Cloud VPN gateways list: classic-vpn, IPv4, default network, australia-southeast1, tunnel classic-vpn-tunnel-1](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/site-to-site-vpn-connection/2025-01-15-15-29-42.png)

If you prefer the CLI, the console steps are roughly equivalent to the commands below. The console also creates the three forwarding rules (ESP, UDP 500, UDP 4500) for you, which is the part people miss when doing it by hand.

```bash
REGION=australia-southeast1
gcloud compute addresses create classic-vpn-ip --region=$REGION
GW_IP=$(gcloud compute addresses describe classic-vpn-ip --region=$REGION --format='value(address)')

gcloud compute target-vpn-gateways create classic-vpn --network=default --region=$REGION

for p in "esp ESP" "udp500 UDP --ports=500" "udp4500 UDP --ports=4500"; do
  set -- $p
  gcloud compute forwarding-rules create classic-vpn-$1 --region=$REGION \
    --address=$GW_IP --target-vpn-gateway=classic-vpn --ip-protocol=$2 $3
done

gcloud compute vpn-tunnels create classic-vpn-tunnel-1 --region=$REGION \
  --target-vpn-gateway=classic-vpn --peer-address=OFFICE_PUBLIC_IP \
  --ike-version=2 --shared-secret="$PSK" \
  --local-traffic-selector=0.0.0.0/0 --remote-traffic-selector=0.0.0.0/0

gcloud compute routes create to-office-lan --network=default \
  --destination-range=192.168.0.0/24 \
  --next-hop-vpn-tunnel=classic-vpn-tunnel-1 --next-hop-vpn-tunnel-region=$REGION
```

## Step 2: Add the Google gateway as a non-Meraki peer

In the Meraki dashboard go to **Security & SD-WAN > Configure > Site-to-site VPN**.

![Meraki Site-to-site VPN: type Hub (Mesh); local networks Main subnet 192.168.0.0/24 and Client VPN 192.168.1.0/24 both VPN mode Enabled](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/site-to-site-vpn-connection/2025-01-15-15-36-10.png)

- **Type:** Hub (Mesh) here.
- **Local networks:** set **VPN mode** to **Enabled** for each subnet that should go over the tunnel. Only enabled subnets are offered to the peer.

Further down, under **Organization-wide settings > Non-Meraki VPN peers**, click **Add a peer**.

![Non-Meraki VPN peers list: peer Google Cloud, IKEv2, Default IPsec policy, IPsec subnet 10.152.0.0/20, All networks](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/site-to-site-vpn-connection/2025-01-15-16-37-21.png)

Fill in the side panel:

![Add VPN Peer: IKEv2, public IP of the Google gateway, shared secret, routing Static, private subnets 10.152.0.0/20, availability All networks](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/site-to-site-vpn-connection/2025-01-15-17-01-50.png)

<Table data={{
  "headers": ["Field", "Value", "Notes"],
  "rows": [
    ["IKE version", "IKEv2", "Same as the Google tunnel"],
    ["Public IP or Hostname", "The Google VPN gateway IP", "From the Cloud VPN gateways list"],
    ["Local ID / Remote ID", "Leave empty", "Not needed for Google with IP-based peers"],
    ["Shared secret", "The pre-shared key from Google", "Paste it, don't type it"],
    ["Routing", "Static", "Dynamic (BGP) needs MX 18.207+"],
    ["Private subnets", "10.152.0.0/20", "The VPC subnet(s) you want to reach"],
    ["Availability", "All networks, or a network tag", "See note below"]
  ]
}} />

**Use the full VPC subnet.** The default VPC subnet in Sydney is 10.152.0.0/20 (10.152.0.0 to 10.152.15.255). If you enter 10.152.0.0/24 instead, the Meraki only sends traffic for 10.152.0.x into the tunnel, and any VM with an address above that is unreachable from the office. Check the subnet range under **VPC networks** rather than guessing. If you also need VMs in other regions of the same VPC, add their subnets too.

**Availability** is organisation-wide. "All networks" means every MX in the Meraki organisation will try to build this tunnel. With one MX that's fine. With several sites, tag the right network and choose that tag, otherwise other sites will try to connect with the same peer settings and Google will only accept the one remote peer IP it knows.

### The IPsec policy

The **Preset** dropdown has Default, AWS, Azure, Umbrella, Zscaler and Custom. There's no Google preset. I left it on **Default**, and these are the values it uses on this firmware:

![Meraki Default IPsec policy: Phase 1 3DES, SHA1, PRF SHA1, DH group 2, lifetime 28800; Phase 2 3DES, AES 128/192/256, MD5, SHA1](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/site-to-site-vpn-connection/2025-01-15-17-07-06.png)

![Phase 2 continued: PFS group Off, lifetime 28800](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/site-to-site-vpn-connection/2025-01-15-17-07-32.png)

A peer with Default (IKEv2, static routing, 10.152.0.0/20) came up green against Google Cloud, so it does work. But the Default preset is built for compatibility: Phase 1 is 3DES, SHA1 and DH group 2, Phase 2 still allows MD5, and PFS is off. Those are all legacy choices. Google Cloud VPN supports stronger options, so for a new tunnel choose **Custom** and set:

<Table data={{
  "headers": ["Setting", "Phase 1 (IKE)", "Phase 2 (IPsec)"],
  "rows": [
    ["Encryption", "AES 256", "AES 256"],
    ["Authentication", "SHA256", "SHA256"],
    ["Pseudo-random function", "SHA256", "n/a"],
    ["Diffie-Hellman / PFS group", "14", "14"],
    ["Lifetime", "28800 (default)", "28800 (default)"]
  ]
}} />

Both sides support these. With IKEv2 the lifetimes aren't negotiated: each end rekeys on its own timer, so you don't need to match Google's values exactly. Change the policy in one go and watch the status page. If the tunnel drops, Google's VPN logs (below) show which proposal it rejected.

Click **Add**, then **Save** at the bottom of the page. The peer isn't applied until you save.

![The new peer row in the Non-Meraki VPN peers list](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/site-to-site-vpn-connection/2025-01-15-17-08-43.png)

## Step 3: Firewall rules on Google Cloud

The tunnel only carries packets. Google's VPC firewall still decides what reaches the VMs, and the `default` VPC's built-in `default-allow-internal` rule only covers 10.128.0.0/9, not your office range. Add an ingress rule for the office subnet, limited to what you need:

```bash
gcloud compute firewall-rules create allow-office-lan \
  --network=default --direction=INGRESS \
  --source-ranges=192.168.0.0/24 \
  --allow=icmp,tcp:22,tcp:3389
```

Swap the ports for your actual services, and add `--target-tags` if only some VMs should be reachable. Also check the VM's own firewall: Windows VMs block inbound ping by default, which looks exactly like a broken tunnel.

On the Meraki side, site-to-site traffic is allowed by default. If you've added rules under **Site-to-site outbound firewall**, make sure they allow the office to the 10.152.0.0/20 range.

## Step 4: Check the tunnel

On Meraki, go to **Organization > Monitor > VPN status**, open the network, and click **Non-Meraki peer**. Green means the tunnel is up:

![Meraki VPN status: 1 Non-Meraki peer, Google Cloud, status green, subnet 10.152.0.0/20](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/site-to-site-vpn-connection/2025-01-15-17-25-41.png)

The "No data available" banner is about usage graphs and can be ignored. On Google Cloud, the tunnel status under **VPN > Cloud VPN tunnels** should say **Established**.

Then test with real traffic: from an office PC, ping or SSH to a VM's **internal** IP (10.152.x.x), and from the VM, ping an office device's 192.168.0.x address.

## Troubleshooting

<Table data={{
  "headers": ["Symptom", "Likely cause", "What to check"],
  "rows": [
    ["Google says 'Waiting for full config' or 'No incoming packets'", "Meraki not sending to the right IP, or peer not saved", "Peer public IP is the Google gateway IP; you clicked Save; office has a real public IP"],
    ["'Negotiation failure' / Meraki status red", "PSK, IKE version or IPsec policy mismatch", "Re-paste the PSK on both sides; both IKEv2; try Default preset to isolate"],
    ["Tunnel green, nothing answers", "Firewall", "Google ingress rule for the office subnet; VM OS firewall"],
    ["Some VMs reachable, others not", "Subnet too narrow on Meraki", "Private subnets uses the full /20 (or all needed subnets)"],
    ["Office can send, replies never arrive", "Google has no route back", "Office subnet listed in the tunnel's remote ranges / static route"],
    ["One VLAN works, another doesn't", "VPN mode off for that VLAN, or not in Google's remote ranges", "Both sides list every subnet that needs to talk"],
    ["Tunnel drops every few hours", "Rekey problem", "Phase 2 settings and PFS group the same on both sides"]
  ]
}} />

For negotiation problems, the most useful detail is in Google's logs. In **Logs Explorer**, filter on resource type **Cloud VPN gateway** (`resource.type="vpn_gateway"`). The IKE messages show which proposal was rejected or whether the key failed to authenticate. On the Meraki side, **Network-wide > Event log** with the VPN event types shows the same negotiation from the other end.

## Related

- [Fixing crackling VoIP calls behind a Meraki MX](/blog/2024-11-28-fixing-voip-poor-sound-quality-and-calls-are-cracking/), on the same office network.
- [Router down: my 3-day battle with Meraki, Ubiquiti and VLANs](/blog/2026/02/10-router-down-my-3-day-battle-with-meraki-ubiquiti--vlans/)
- If you're looking for newer MX hardware with BGP support, the [Meraki MX range is listed in our store](https://store.tyo.com.au/shop/meraki/sd-wan/).

<ContactFooter />


a39af46c8ed0a77b745bce2b26b961c0008041bc7caa698bada965f035f1fd8f

Connect a Meraki MX to a Google Cloud VPC with Classic VPN: IKEv2, static routes, matching subnets, a stronger IPsec policy and firewall rules.

How to connect an office behind a Meraki MX to a Google Cloud VPC with a Classic VPN tunnel and static routes: the exact settings on both sides, why Classic instead of HA VPN on older MX models, a stronger IPsec policy than the Meraki default, and what to check when the tunnel is up but nothing answers.

Tag: Google Cloud

Tag: Google Cloud

Cloud Run Domain Mappings with Cloudflare: Why Your SSL is Stuck

Meraki MX to Google Cloud Site-to-Site VPN (Classic VPN, Static Routing)